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Abstract 


This document provides an overview of the Operations, Administration, 
and Maintenance (OAM) toolset for MPLS-based transport networks. The 
toolset consists of a comprehensive set of fault management and 
performance monitoring capabilities (operating in the data plane) 
that are appropriate for transport networks as required in RFC 5860 
and support the network and services at different nested levels. 

This overview includes a brief recap of the MPLS Transport Profile 
(MPLS-TP) OAM requirements and functions and the generic mechanisms 
created in the MPLS data plane that allow the OAM packets to run 
in-band and share their fate with data packets. The protocol 
definitions for each of the MPLS-TP OAM tools are defined in separate 
documents (RFCs or Working Group documents), which are referenced by 
this document. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any 


errata, and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6669. 
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1. Introduction 
1.1. Scope 


The MPLS Transport Profile (MPLS-TP) architectural framework is 
defined in [RFC5921], and it describes a common set of protocol 
functions that supports the operational models and capabilities 
typical of such transport networks. 


Operations, Administration, and Maintenance (OAM) plays a significant 
role in carrier networks. It provides methods for fault management 
and performance monitoring in both the transport and service layers, 
in order to improve their ability to support services with guaranteed 
and strict Service Level Agreements (SLAs) while reducing their 
operational costs. 


[RFC5654], in general, and [RFC5860], in particular, define a set of 
requirements for the OAM functionality for MPLS-TP Label Switched 
Paths (LSPs), Pseudowires (PWs), and Sections. 


The OAM solution, developed by the joint IETF and ITU-T MPLS-TP 
project, has three objectives: 


o The OAM toolset should be developed based on existing MPLS 
architecture, technology, and toolsets. 


o The OAM operational experience should be similar to that in other 
transport networks. 


o The OAM toolset developed for MPLS-based transport networks needs 
to be fully interoperable with existing MPLS OAM tools as 
documented in Section 2.1.5. of [RFC5860]. 

The MPLS-TP OAM toolset is based on the following existing tools: 

o LSP ping, as defined in [RFC4379]. 


o Bidirectional Forwarding Detection (BFD), as defined in [RFC5880] 
and refined in [RFC5884]. 


o ITU-T OAM for the Ethernet toolset, as defined in [Y.1731]. This 
has been used as functionality guidelines for the performance 
measurement tools that were not previously supported in MPLS. 


Note that certain extensions and adjustments have been specified, 
relative to the existing MPLS tools, in order to conform to the 
transport environment and the requirements of MPLS-TP. However, 
compatibility with the existing MPLS tools has been maintained. 
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This document provides an overview of the MPLS-TP OAM toolset, which 
consists of tools for MPLS-TP fault management and performance 
monitoring. This overview includes a brief recap of MPLS-TP OAM 
requirements, their functions, and the generic mechanisms used to 
support the MPLS-TP OAM operation. 


The protocol definitions for individual MPLS-TP OAM tools are 
specified in separate RFCs (or Working Group documents), which are 
referenced by this document. 


In addition, this document includes a table that cross-references the 
solution documents of the OAM functionality supported. Finally, the 
document presents the applicability and utilization of each tool in 
the MPLS-TP OAM toolset. 


1.2. Acronyms 


This document uses the following acronyms: 


ACH Associated Channel Header 

AIS Alarm Indication Signal 

BFD Bidirectional Forwarding Detection 

CC-CV Continuity Check and Connectivity Verification 
DM Delay Measurement 

FM Fault Management 

G-ACh Generic Associated Channel 

GAL G-ACh Label 

GMPLS Generalized Multiprotocol Label Switching 
IANA Internet Assigned Numbers Authority 

LDI Link Down Indication 

LKR Lock Report 

LM Loss Measurement 

LOC Loss of Continuity 

LSP Label Switched Path 

MEP Maintenance Entity Group End Point 

MEG Maintenance Entity Group 

MIP Maintenance Entity Group Intermediate Point 
MPLS Multiprotocol Label Switching 

MPLS-TP Transport Profile for MPLS 

OAM Operations, Administration, and Maintenance 
PM Performance Monitoring 

PW Pseudowire 

RDI Remote Defect Indication 

SLA Service Level Agreement 

TLV Type, Length, Value 

VCCV Virtual Circuit Connectivity Verification 
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2's 


Basic OAM Infrastructure Functionality 


[RFC5860] defines a set of requirements for OAM architecture and 
general principles of operations, which are evaluated below: 


[RFC5860] requires that -- 


o 


OAM mechanisms in MPLS-TP are independent of the transmission 
media and the client service being emulated by the PW ([RFC5860], 
Section 2.1.2). 


MPLS-TP OAM must be able to support both an IP-based and non-IP- 


based environment. If the network is IP based, i.e., IP routing 
and forwarding are available, then it must be possible to choose 
to make use of IP capabilities. On the other hand, in 


environments where IP functionality is not available, the OAM 
tools must still be able to operate independent of IP forwarding 
and routing ([RFC5860], Section 2.1.4). It is required to have 
OAM interoperability between distinct domains materializing the 
environments ([RFC5860], Section 2.1.5). 


A11 OAM protocols support identification information, at least in 
the form of IP addressing structure, and are extensible to support 
additional identification schemes ([RFC5860], Section 2.1.4). 


OAM packets and the user traffic are congruent (i.e., OAM packets 
are transmitted in-band) and there is a need to differentiate OAM 
packets from user-plane packets [RFC5860], Section 2.1.3. 

Inherent in this requirement is the principle that full operation 
of the MPLS-TP OAM must be possible independently of the control 
or management plane used to operate the network [RFC5860], Section 
2.1.3 


MPLS-TP OAM supports point-to-point bidirectional PWs, point-to- 
point co-routed bidirectional LSPs, and point-to-point 
bidirectional Sections ([RFC5860], Section 2.1.1). The 
applicability of particular MPLS-TP OAM functions to point-to- 
point associated bidirectional LSPs, point-to-point unidirectional 
LSPs, and point-to-multipoint LSPs, is described in [RFC5860], 
Section 2.2. In addition, MPLS-TP OAM supports these LSPs and PWs 
when they span either single or multiple domains ([RFC5860], 
Section 2.1.1). 


OAM packets may be directed to an intermediate point of an LSP/PW 
([REC5860], Sections 2.2.3, 2.2.4, and 2.2.5). 
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[RFC5860], Section 2.2 recommends that any protocol solution meeting 
one or more functional requirement (s) be the same for PWs, LSPs, and 
Sections. 


The following document set addresses the basic requirements listed 
above: 


o [RFC6371] describes the architectural framework for conformance to 
the basic requirements listed above. It also defines the basic 
relationships between the MPLS structures, e.g., LSP, PW, and the 
structures necessary for OAM functionality, i.e., the Maintenance 
Entity Group (MEG), its end points, and intermediate points. 


o [RFC5586] specifies the use of the MPLS-TP in-band control 
channels. It generalizes the applicability of the PW ACH to MPLS 
LSPs and Sections by defining a Generic Associated Channel 


(G-ACh). The G-ACh allows control packets to be multiplexed 
transparently over LSPs and Sections similar to that of PW VCCV 
[RFC5085]. The Generic Association Label (GAL) is defined by 


assigning a reserved MPLS label value and is used to identify the 
OAM control packets. The value of the ACH Channel Type field 
indicates the specific protocol carried on the associated control 
channel. Each MPLS-TP OAM protocol has an IANA-assigned channel 
type allocated to it. 


[RFC5085] defines an Associated Channel Header (ACH) that provides a 
PW associated control channel between a PW’s end points, over which 
OAM and other control messages can be exchanged. [RFC5586] 
generalizes the PW Associated Channel Header (ACH) to provide common 
in-band control channels also at the LSP and MPLS-TP link levels. 

The G-ACh allows control packets to be multiplexed transparently over 
the same LSP or MPLS-TP link as in PW VCCV. Multiple control 
channels can exist between end points. 


[RFC5085] also defines a label-based exception mechanism that helps a 
Label Switching Router (LSR) to identify the control packets and 
direct them to the appropriate entity for processing. The use of 
G-ACh and GAL provides the necessary mechanisms to allow OAM packets 
to run in-band and share their fate with data packets. It is 
expected that all of the OAM protocols will be used in conjunction 
with this Generic Associated Channel. 


o [RFC6370] provides an IP-based identifier set for MPLS-TP that can 


be used to identify the transport entities in the network and 
referenced by the different OAM protocols. 


Sprecher & Fang Informational [Page 7] 


RFC 6669 OAM Toolset July 2012 


Note: [MPLS-TP-ITU-Idents] augments that set of identifiers to 
include identifier information in a format used by the ITU-T. 
Other identifier sets may be defined as well. 


3. MPLS-TP OAM Functions 


The following sections discuss the OAM functions that are required in 
[RFC5860] and expanded upon in [RFC6371]. 


3.1. Continuity Check and Connectivity Verification 


Continuity Check and Connectivity Verification (CC-CV) are OAM 
operations generally used in tandem and complement each other. These 
functions are generally run proactively, but may also be used 
on-demand for diagnoses of a specific condition. [RFC5860] states 
that the function should allow the MEPs to proactively monitor the 
liveliness and connectivity of a transport path (LSP, PW, ora 
Section) between them. In on-demand mode, this function should 
support monitoring between the MEPs and between a MEP and MIP. Note 
that as specified in [RFC6371], Sections 3.3 and 3.4, a MEP and a MIP 
can reside in an unspecified location within a node, or ina 
particular interface on a specific side of the forwarding engine. 


[RFC6371] highlights the need for the CC-CV messages to include 
unique identification of the MEG that is being monitored and the MEP 
that originated the message. The function, both proactively and in 
on-demand mode, needs to be transmitted at regular transmission rates 
pre-configured by the operator. 


3.1.1. Documents for CC-CV Tools 


[RFC6428] defines BFD extensions to support proactive CC-CV 
applications. 


[RFC6426] provides LSP ping extensions that are used to implement 
on-demand connectivity verification. 


Both of these tools will be used within the basic functionality 
framework described in Section 2. 


3.2. Remote Defect Indication 


Remote Defect Indication (RDI) is used by a path end point to report 
that a defect is detected on a bidirectional connection to its peer 
end point. [RFC5860] points out that this function may be applied to 
a unidirectional LSP only if a return path exists. [RFC6371] points 
out that this function is associated with the proactive CC-CV 
function. 
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3.2.1. Documents for RDI 


[RFC6428] provides an extension for BFD that includes the RDI 
indication in the BFD format and a specification of how this 
indication is to be used. 


3.3. Route Tracing 


[RFC5860] defines the need for functionality that would allow a path 
end point to identify the intermediate points (if any) and end 
point(s) along the path (LSP, PW, or a Section). This function would 
be used in on-demand mode. Normally, this path will be used for 
bidirectional PW, LSP, and Sections; however, unidirectional paths 
may be supported only if a return path exists. 


3.3.1. Documents for Route Tracing 


[RFC6426] specifies that the LSP ping enhancements for MPLS-TP on- 
demand connectivity verification include information on the use of 
LSP ping for route tracing of an MPLS-TP path. 


3.4. Alarm Reporting 


Alarm Reporting is a function used by an intermediate point of a path 
(LSP or PW) to report to the end points of the path that a fault 
exists on the path. [RFC6371] states that this may occur as a result 
of a defect condition discovered at a server layer. The intermediate 
point generates an Alarm Indication Signal (AIS) that continues until 
the fault is cleared. The consequent action of this function is 
detailed in [RFC6371]. 


3.4.1. Documents for Alarm Reporting 


MPLS-TP defines a new protocol to address this functionality that is 
documented in [RFC6427]. This protocol uses all of the basic 
mechanisms detailed in Section 2. 


3.5. Lock Instruct 


The Lock Instruct function is an administrative control tool that 
allows a path end point to instruct its peer end point to lock the 
path (LSP, PW, or Section). The tool is necessary to support single- 
side provisioning for administrative locking, according to [RFC6371]. 
This function is used on-demand. 
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3.5.1. Documents for Lock Instruct 


[RFC6435] describes the details of a new ACH-based protocol format 
for this functionality. 


3.6. Lock Reporting 


Lock Reporting, defined in [RFC5860], is similar to the Alarm 
Reporting function described above. It is used by an intermediate 
point to notify the end points of a transport path (LSP or PW) that 
an administrative lock condition exists for the transport path. 


3.6.1. Documents for Lock Reporting 


MPLS-TP defines a new protocol to address this functionality that is 
documented in [RFC6427]. This protocol uses all the basic mechanisms 
detailed in Section 2. 


3.7. Diagnostic 


[RFC5860] indicates a need to provide an OAM function that would 
enable conducting different diagnostic tests on a PW, LSP, or 
Section. [RFC6371] provides two types of specific tests to be used 
through this functionality: 


o Throughput estimation - allowing the provider to verify the 
bandwidth/throughput of a transport path. This is an out-of- 
service tool that uses special packets of varying sizes to test 
the actual bandwidth and/or throughput of the path. 


o Data-plane loopback - this out-of-service tool causes all traffic 
that reaches the target node, either a MEP or MIP, to be looped 
back to the originating MEP. For targeting MIPs, a co-routed 
bidirectional path is required. 


3.7.1. Documents for Diagnostic Testing 


[RFC6435] describes the details of a new ACH-based protocol format 
for the data-plane loopback functionality. 


The tool for throughput estimation is under study. 

3.8. Packet Loss Measurement 
Packet Loss Measurement is required by [RFC5860] to provide a 
quantification of the packet loss ratio on a transport path. This is 


the ratio of the number of user packets lost to the total number of 
user packets during a defined time interval. To employ this 
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function, [RFC6371] defines that the two end points of the transport 
path should exchange counters of messages transmitted and received 
within a time period bounded by loss-measurement messages. The 
framework warns that there may be small errors in the computation, 
which result from various issues. 


3.8.1. Documents for Packet Loss Measurement 


[RFC6374] describes the protocol formats and procedures for using the 
tool and enabling efficient and accurate measurement of packet loss, 
delay, and throughput in MPLS networks. [RFC6375] describes a 
profile of the general MPLS loss, delay, and throughput measurement 
techniques that suffice to meet the specific requirements of MPLS-TP. 
Note that the tool logic is based on the behavior of the parallel 
function described in [Y.1731]. 


3.9. Packet Delay Measurement 


Packet Delay Measurement is a function that is used to measure the 
one-way or two-way delay of packet transmission between a pair of the 
end points of a path (PW, LSP, or Section), as described in 
[RFC5860], where: 


o One-way packet delay is the time elapsed from the start of 
transmission of the first bit of the packet by a source node until 
the reception of the last bit of that packet by the destination 
node. 


o Two-way packet delay is the time elapsed from the start of 
transmission of the first bit of the packet by a source node until 
the reception of the last bit of the loop-backed packet by the 
same source node, when the loopback is performed at the packet’s 
destination node. 


[RFC6371] describes how the tool could be used (both in proactive and 
on-demand modes) for either one-way or two-way measurement. However, 
it warns that the one-way delay option requires precise time 
synchronization between the end points. 


3.9.1. Documents for Delay Measurement 


[RFC6374] describes the protocol formats and procedures for using the 
tool and enabling efficient and accurate measurement of packet loss, 
delay, and throughput in MPLS networks. [RFC6375] describes a 
profile of the general MPLS loss, delay, and throughput measurement 
techniques that suffices to meet the specific requirements of MPLS- 
TP. Note that the tool logic is based on the behavior of the 
parallel function described in [Y.1731]. 
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4. 


MPLS-TP OAM Documents Guide 


The complete MPLS-TP OAM protocol suite is covered by a small set of 
existing IETF documents. This set of documents may be expanded in 
the future to cover additional OAM functionality. In order to allow 
the reader to understand this set of documents, a cross-reference of 
the existing documents (RFCs or Working Group documents) for the 
initial phase of the specification of MPLS-based transport networks 
is provided below. 


[RFC5586] provides a specification of the basic structure of protocol 
messages for in-band data-plane OAM in an MPLS environment. 


[RFC6370] provides definitions of different formats that may be used 
within OAM protocol messages to identify the network elements of an 
MPLS-based transport network. 


The following table (Table 1) provides the summary of proactive MPLS- 
TP OAM Fault Management toolset functions, the associated 
tool/protocol, and the corresponding RFCs in which they are defined. 


4+-------------------------- Ho oo 4+--------- + 
| OAM Functions | OAM Tools/Protocols | RFCs 

Ho oo 4+------------------------------- 4+--------- + 
| Continuity Check and | Bidirectional Forwarding | [RFC6428] | 
| Connectivity | Detection (BFD) | 

| Verification | | | 
+—-------------------------- 4+------------------------------- +--------- + 
| Remote Defect Indication | Flag in Bidirectional | [RFC6428] | 
| (RDI) | Forwarding Detection (BFD) | 

| | message | | 
4+—-------------------------- 4+------------------------------- 4+--------- + 
| Alarm Indication Signal | G-ACh-based AIS message | [RFC6427] | 
| (ATS) | | | 
Ho ooo 4+------------------------------- +--------- + 
| Link Down Indication | Flag in AIS message | [RFC6427] | 
| (LDI) | | | 
4+—-------------------------- 4+------------------------------- +--------- + 
| Lock Reporting (LKR) | G-ACh-based LKR message | [RFC6427] | 
a A A An : 


Table 1. Proactive Fault Management OAM Toolset 
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The following table (Table 2) provides an overview of the on-demand 
MPLS-TP OAM Fault Management toolset functions, the associated 
tool/protocol, and the corresponding RFCs in which they are defined. 


$ r Sede += + 232322 ASS SS SSS SS AS Ho + 
| OAM Functions | OAM Tools/Protocols | RFCs 
+------------------------ $ O TET Ho + 
| Connectivity | LSP Ping | [RFC6426] | 
| Verification | | | 
e E T O ase SSS SSS se Se eee eee HS + 
| Lock Instruct (LI) | (1) G-ACh-based Loopback, | [RFC6426] | 
| | (2) Lock Instruct (LI) | | 
a a a eS a aa 45222275 + 
| Lock Report (LKR) | Flag in AIS message ee 
AA A ae eee feces : 
Table 2. On Demand Fault Management OAM Toolset 
The following table (Table 3) provides the Performance Monitoring 
Functions, the associated tool/protocol definitions, and the 
corresponding RFCs in which they are defined. 
po SSeS Se Se SSS SS a ia a a ai + 
| OAM Functions | OAM Tools/Protocols | RFCs 
e pasa=== NT T H====>=8========2= + 
| Packet Loss | G-ACh-based LM & DM | [RFC6374] | 
| Measurement (LM) | query messages | [RFC6375] | 
+---------------------- $ S A R A E E +—----------------- + 
| Packet Delay | G-ACh-based LM & DM | [RFC6374] | 
| Measurement (DM) | query messages | [RFC6375] | 
+---------------------- A A la tla +----------------- + 
| Throughput | derived from Loss | [RFC6374] | 
| Measurement | Measurement | [RFC6375] | 
a a a aS Se See SSeS se mon oar ipsa ae aaa + 
| Delay Variation | derived from Delay | [RFC6374] | 
| Measurement | Measurement | [RFC6375] | 
n A E A O S Haste ++os32e HS Sto eS + 
Table 3. Performance Monitoring OAM Toolset 


5. OAM Toolset Applicability and Utilization 
The following subsections present the MPLS-TP OAM toolset from the 


perspective of the specified protocols and identifies the required 
functionality that is supported by the particular protocol. 
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5.1. Connectivity Check and Connectivity Verification 


Proactive Continuity Check and Connectivity Verification (CC-CV) 
functions are used to detect loss of continuity (LOC) and unintended 
connectivity between two MEPs. Loss of connectivity, mis-merging, 
mis-connectivity, or unexpected Maintenance Entity Group End Points 
(MEPs) can be detected using the CC-CV tools. See Sections 3.1, 3.2, 
3.3 in this document for CC-CV protocol references. 


The CC-CV tools are used to support MPLS-TP fault management, 
performance management, and protection switching. Proactive CC-CV 
control packets are sent by the source MEP to the sink MEP. The 
sink-MEP monitors the arrival of the CC-CV control packets and 
detects the defect. For bidirectional transport paths, the CC-CV 
protocol is usually transmitted simultaneously in both directions. 


The transmission interval of the CC-CV control packets Can be 
configured. For example: 


o 3.3 ms is the default interval for protection switching. 
o 100 ms is the default interval for performance monitoring. 
o 1s is the default interval for fault management. 

5.2. Diagnostic Tests and Lock Instruct 


[RFC6435] describes a protocol that provides a mechanism to Lock and 
Unlock traffic (e.g., data and control traffic or specific OAM 
traffic) at a specific LSR on the path of the MPLS-TP LSP to allow 
loopback of the traffic to the source. 


These diagnostic functions apply to associated bidirectional MPLS-TP 
LSPs, including MPLS-TP LSPs, bidirectional RSVP-Traffic Engineering 
(RSVP-TE) tunnels (which is relevant for the MPLS-TP dynamic control- 
plane option with GMPLS), and single-segment and multi-segment 
Pseudowires. [RFC6435] provides the protocol definition for 
diagnostic tests functions. 


[RFC6435] defines a mechanism where a lock instruction is sent by a 
management application to both ends of a point-to-point LSP, 
requesting them to take the LSP out-of-service. When an end point 
gets the management request, it locks the LSP and sends a Lock 
Instruct message to the other end of the LSP. The Lock Instruct 
message is carried in a Generic ACH message and is sent periodically. 
The time between successive messages is no longer than the value set 
in the Refresh Timer field of the Lock Instruct message. An LSP end 
point keeps the LSP locked while it is either receiving the periodic 
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Lock Instruct messages or has an in-force lock instruction from the 
management application. 


Note that since the management application will receive a management 
plane response from both ends of the LSP confirming that the LSP has 
been locked, there is no requirement for the Lock Instruct message to 
have a response. Therefore, [RFC6435] does not define a Lock 
Instruct response message. 


The loopback operations include: 

o Lock: take an LSP out of service for maintenance. 

o Unlock: Restore a previously locked LSP to service. 
o Set_Full_Loopback and Set_OAM Loopback. 

o Unset_Full_Loopback and Set_OAM_Loopback. 


Operators can use the loopback mode to test the connectivity or 
performance (loss, delay, delay variation, and throughput) of a given 
LSP up to a specific node on the path of the LSP. 


5.3. Lock Reporting 


The Lock Report (LKR) function is used to communicate to the MEPS of 
the client (sub-)layer MEPs the administrative locking of a server 
(sub-) layer MEP, and consequential interruption of data traffic 
forwarding in the client layer. See Section 3.6 in this document for 
Lock Reporting protocol references. 


When an operator is taking the LSP out of service for maintenance or 
another operational reason, using the LKR function can help to 
distinguish the condition as administrative locking from a defect 
condition. 


The Lock Report function may also serve the purpose of alarm 
suppression in the MPLS-TP network above the level at which the Lock 
has occurred. The receipt of an LKR message may be treated as the 
equivalent of the loss of continuity at the client layer. 


5.4. Alarm Reporting and Link Down Indication 
Alarm Indication Signal (AIS) message is used to suppress alarms 
following detection of defect conditions at the server (sub-) layer. 


When the Link Down Indication (LDI) is set, the AIS message may be 
used to trigger recovery mechanisms. 
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When a server MEP detects the failure, it asserts LOC or signal fail, 
which sets the flag up to generate an OAM packet with the AIS 
message. The AIS message is forwarded to the downstream sink MEP in 
the client layer. This enables the client layer to suppress the 
generation of secondary alarms. 


An LDI flag is defined in the AIS message. The LDI flag is set in 
the AIS message in response to detecting a fatal failure in the 
server layer. Receipt of an AIS message with this flag set may be 
interpreted by a MEP as an indication of signal fail at the client 
layer. 


The protocols for AIS and LDI are defined in [RFC6427]. 


Fault OAM messages are generated by intermediate nodes where an LSP 
is switched and propagated to the end points (MEPs). 


From a practical point of view, when both proactive Continuity Check 
functions and LDI are used, one may consider running the proactive 
Continuity Check functions at a slower rate (e.g., longer BFD hello 
intervals), and reply on LDI to trigger fast protection switch over 
upon failure detection in a given LSP. 


5.5. Remote Defect Indication 


The Remote Defect Indication (RDI) function enables an end point to 
report to its peer end point that a fault or defect condition is 
detected on the PW, LSP, or Section. 


The RDI OAM function is supported by the use of BFD control packets 
[RFC6428]. RDI is only used for bidirectional connections and is 
associated with proactive CC-CV activation. 


When an end point (MEP) detects a signal failure condition, it sets 
the flag up by setting the diagnostic field of the BFD control packet 
to a particular value to indicate the failure condition on the 
associated PW, LSP, or Section. Additionally, the BFD control packet 
is transmitted with the failure flag up to the other end point (its 
peer MEP). 


The RDI function can be used to facilitate protection switching by 


synchronizing the two end points when unidirectional failure occurs 
and is detected by one end. 
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5.6. Packet Loss and Delay Measurement 


The packet loss and delay measurement toolset enables operators to 
measure the quality of the packet transmission over a PW, LSP, or 
Section. Section 3.8 in this document defines the protocols for 
packet loss measurement, and Section 3.9 defines the protocols for 
packet delay measurement. 


The loss and delay protocols have the following characteristics and 
capabilities: 


o They support the measurement of packet loss, delay, and throughput 
over Label Switched Paths (LSPs), Pseudowires, and MPLS Sections. 


o The same LM and DM protocols can be used for both 
continuous/proactive and selective/on-demand measurements. 


o The LM and DM protocols use a simple query/response model for 
bidirectional measurement that allows a single node -- the querier 
-- to measure the loss or delay in both directions. 


o The LM and DM protocols use query messages for unidirectional loss 
and delay measurement. The measurement can either be carried out 
at the downstream node(s), or at the querier if an out-of-band 
return path is available. 


o The LM and DM protocols do not require that the transmit-and- 
receive interfaces be the same when performing bidirectional 
measurement. 


o The LM supports test-message-based measurement (i.e., inferred 
mode) as well as measurement based on data-plane counters (i.e., 
direct mode). 


o The LM protocol supports both 32-bit and 64-bit counters. 
o The LM protocol supports measurement in terms of both packet 
counts and octet counts; although for simplicity, only packet 


counters are currently included in the MPLS-TP profile. 


o The LM protocol can be used to measure channel throughput as well 
as packet loss. 


o The DM protocol supports varying the measurement message size in 
order to measure delays associated with different packet sizes. 


o The DM protocol uses IEEE 1588 timestamps [IEEE1588] by default 
but also supports other timestamp formats, such as NTP. 
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6. 


Security Considerations 


This document, as an overview of MPLS OAM tools, does not by itself 
raise any particular security considerations. 


The general security considerations are provided in [RFC5920] and 
[MPLS-TP-SEC]. Security considerations for each function within the 
OAM toolset have been recorded in each document that specifies a 
particular functionality. 


In general, OAM is always an area where the security risk is high. 
For example, confidential information may be intercepted by attackers 
to gain access to networks; therefore, authentication, authorization, 
and encryption must be enforced to prevent security breaches. 


It is also important to strictly follow operational security 
procedures. For example, in the case of MPLS-TP static provisioning, 
the operator interacts directly with the Network Management System 
(NMS) and devices, and it is critical in order to prevent human 
errors and malicious attacks. 


Since MPLS-TP OAM uses G-ACh, the security risks and mitigations 
described in [RFC5085] also apply here. In short, messages on the 
G-ACh could be intercepted, or false G-ACh packets could be inserted. 


Additionally, DoS attacks can be mounted by flooding G-ACh messages 
to peer devices. To mitigate this type of attack, throttling 
mechanisms or rate limits can be used. For more details, please see 
[RFC5085]. 
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